1. Field of the Invention
This invention relates to Manufacturing Executing Systems (MES) and, more particularly, to a protocol used to communicate between servers and clients operating in a MES environment.
2. Glossary of Terms
The following terms and definitions are offered in order to facilitate understanding of the invention:
CIMComputer Integrated ManufacturingCORBACommon Object Request Broker Architecture is theOMG platform-independent technique for programsrunning on different machines to communicatewith each other.IDLInterface Definition Language. Generally refersto the OMG/CORBA IDL. Used to define interfaces toobjects. Defines the types of objects accordingto the operations that may be performed on themand the parameters to those operations. Thisis similar to a C++ header file. For example, in theCORBA context, an IDL compiler generates “stubs”that can be called by client code and skeletons forimplementing server code. IDL compilers existto map the IDL definitions into various languages:C, C++, Smalltalk, Java.MESManufacturing Execution SystemsOMGObject Management GroupSEMATECHSEmiconductor MAnufacturing TECHnology: aninternational research consortium in whichmember companies cooperate precompetitively in keyareas of semiconductor technology, sharing expensesand risk with the common aim of acceleratingdevelopment of advanced manufacturing technologies.SiView StandardAn integrated Manufacturing Execution System(MES) and equipment automation offering from IBMthat is compatible with the SEMY/SEMATECHCIM Framework and Object Management Group(OMG) standards. It uses object-oriented technologywith plug-and-play flexibility to permit fine tuningof operational performance as needed.XMLeXtensible Markup Language: a W3C proposedrecommendation. Like HTML, XML is a simplifiedprofile of SGML, for creating markup languages.XML: may be used to define many differentdocument types, each of which uses its own elementtype names.HTMLHyper Text Markup Language uses a single SGMLdocument type, with a fixed set of element type names,i.e., “tag names,” such as “html”, “body”, “h1”, “o1”.SGMLAn International Standard (ISO 8879)
3. Background of the Art
In large manufacturing facilities, such as a semiconductor foundry in which many tools are required to build the wafer and chip product, there exist many complex software programs or packages that are used to run and monitor the performance of the tools. Many of these monitoring and control software packages are written to standards defined by the semiconductor equipment consortium SEMATEC. SEMATEC standards are typically used as they guide manufacturers in the way these programs should be implemented. The main framework for this system of software programs is known as the Computer Implemented Manufacturing (CIM) framework.
The overall control of the tools in the foundry is by a central computer or server having a Manufacturing Execution System (MES) tool control system. The central server has the information regarding each customer job that is currently being processed and ensures that each tool is performing the correct operation and in the appropriate sequence. This server communicates with users that monitor and control the production flow and operations on individual client workstations. A MES of the type suitable for this purpose is sold under the model name SiView and is published by International Business Machine Corp. (IBM) of Armonk, N.Y. SiView and IBM are registered trademarks of the IBM Corporation.
Currently, one of the goals of SEMATECH is to adopt a distributed communications pathway and protocol that is referred to as Common Object Request Broker Architecture (CORBA). This system allows for the development of distributed systems to operate seamlessly in an integrated architecture while functioning on various independent platforms. MES architectures, such as SiView, are following the recommendations of SEMATECH and are transitioning over to CORBA. With reference to FIG. 1, an example of a communication pathway 100 using CORBA 120 connects server 110 and client device 130. Communication files are initiated through the CORBA communication pathway 120 using objects stored for use in a CORBA communication pathway using IDL files 115, 125.
While suitable for its intended purpose one drawback to the use of IDL is that complex monitoring and control tasks can result in the use of many objects or software modules resulting in a large collection of IDL files to accomplish a specific task. This build-up of IDL files 115, 115a, 115b, etc., over time, adds complexity and additional overhead to the communication pathway. For example, a server may initially provide for the monitoring of two functions, such as “lot track in” and “lot track out,” wherein “lot track in” may be representative of a monitoring function that monitors the input of a product lot and “lot track out” may be representative of a monitoring function that monitors the output of the production lot. In this case the IDL file contains two methods. Over time, as the desire to monitor more features grows and the capability to monitor more features increases, more functions may be added to enhance the server's capability. For example, functions such as “lot information inquiry,” “operation history inquiry,” “tool information inquiry,” “lot running hold” may be functions that are desired and added.
One method of organizing these new functions may be to develop categories of operations that include one IDL file per category. For example categories may be represented as:                Category 1-Action applied on lot;        Category 2-Information inquiry on lot;        Category 3-Action applied on tool;        Category 4-flow/routing setting; and        Category 5-modeling recipe manipulation        
Thus, an IDL file associated with Category 1 may monitor or track the input and output of material, for example. Category 2 may include an IDL file for a “query of lot information” or a “lot operation history.” Category 3 may include an IDL file for setting or resetting the operation mode of a tool or for requesting a “tool operational status.” Category 4 may include an IDL file for flow management or route settings and Category 5 may include an IDL file for modeling individual recipes.
However, an IDL file may become diverse and complex as new functions are added to the file. For example, an IDL file, entitled “File A” associated with category 1: (version 1.0), may monitor input and output using the following instructions shown here in the well known IDL programming language as:
File A: “basic_result_structure”Interface ActionOnLot {TrackInResult = Trackin( );TrackOutResult = TrackOut( )
However, a user may need or desire additional actions such as “hold/release.”In this case, IDL file, File A, may be modified as:
File A: “basic_result_structure”Interface ActionOnLot {TrackInResult = TrackIn( );TrackOutResult = TrackOut( );HoldResult=hold( );ReleaseResult=release( );
Users may desire to enhance the hold function with functions such as “future hold,” “hold right now,” and “hold after current operation complete.” In this case, the IDL file, entitled “File A1,” may be represented as:
File A1include “file A”include “Enhanced_Result_Structure”interface enhancedActionOnLot : basicActionOnLot {future_hold_result = future_hold( );enhanced_hold_result_1 = hold(in stringFlag_HoldRightNow?);hold_next_result = hold_next( );enhanced_release_result = release(in string user_id);//check user id.
In this case “File A,” which has many of the desired features, is included in the new process, “File A1.” Thus, as new functions are added to the monitoring process, an increase in the complexity and number of the IDL statements naturally occurs. However, changes to basic IDL functions, such as File A, may cause operations of more complex functions to operate in an unexpected and undesired manner.
Accordingly, there is a need for a method and system that allows for improved monitoring and tracking capability without significant increase in the complexity of the programming instructions performing the monitoring operations.